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Abstract 


This document defines a binary format for representing HTTP messages. 


Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force (IETF). It represents the 
consensus of the IETF community. It has received public review and has been approved for 
publication by the Internet Engineering Steering Group (IESG). Further information on Internet 
Standards is available in Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc9292. 


Copyright Notice 


Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights 
reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
with respect to this document. Code Components extracted from this document must include 
Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are 
provided without warranty as described in the Revised BSD License. 
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1. Introduction 


This document defines a simple format for representing an HTTP message [HTTP], either request 
or response. This allows for the encoding of HTTP messages that can be conveyed outside an 
HTTP protocol. This enables the transformation of entire messages, including the application of 
authenticated encryption. 


The design of this format is informed by the framing structure of HTTP/2 [HTTP/2] and HTTP/3 
[HTTP/3]. Rules for constructing messages rely on the rules defined in HTTP/2, but the format 
itself is distinct; see Section 6. 


This format defines "message/bhttp", a binary alternative to the "message/http" content type 
defined in [HTTP/1.1]. A binary format permits more efficient encoding and processing of 
messages. A binary format also reduces exposure to security problems related to processing of 
HTTP messages. 


Two modes for encoding are described: 


e a known-length encoding includes length prefixes for all major message components, and 


e an indeterminate-length encoding enables efficient generation of messages where lengths 
are not known when encoding starts. 


This format is designed to convey the semantics of valid HTTP messages as simply and efficiently 
as possible. It is not designed to capture all of the details of the encoding of messages from 
specific HTTP versions [HTTP/1.1] [HTTP/2] [HTTP/3]. As such, this format is unlikely to be 
suitable for applications that depend on an exact recording of the encoding of messages. 


2. Conventions and Definitions 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 
NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to 
be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in 
all capitals, as shown here. 


This document uses terminology from HTTP [HTTP] and notation from QUIC (Section 1.3 of 
[QUIC]). 
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3. Format 


Section 6 of [HTTP] defines the general structure of HTTP messages and composes those 
messages into distinct parts. This format describes how those parts are composed into a 
sequence of bytes. At a high level, binary messages are comprised of: 


1. Framing indicator. This format uses a single integer to describe framing, which describes 
whether the message is a request or response and how subsequent sections are formatted; 
see Section 3.3. 


N 


. For a response, zero or more informational responses. Each informational response consists 
of an informational status code and header section. 


Ww 


. Control data. For a request, this contains the request method and target. For a response, this 
contains the status code. 


. Header section. This contains zero or more header fields. 
. Content. This is a sequence of zero or more bytes. 
Trailer section. This contains zero or more trailer fields. 


ypu p 


Optional padding. Any amount of zero-valued bytes. 


All lengths and numeric values are encoded using the variable-length integer encoding from 
Section 16 of [QUIC]. Integer values do not need to be encoded on the minimum number of bytes 
necessary. 


3.1. Known-Length Messages 


A request or response that has a known length at the time of construction uses the format shown 
in Figure 1. 
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Known-Length Request { 
Framing Indicator (i) = 8, 
Request Control Data (..), 
Known-Length Field Section (..), 
Known-Length Content (..), 
Known-Length Field Section (..), 
Padding (..), 

} 


Known-Length Response { 
Framing Indicator (i) = 1, 
Known-Length Informational Response (..) ..., 
Final Response Control Data (..), 
Known-Length Field Section (..), 
Known-Length Content (..), 
Known-Length Field Section (..), 


Padding (..), 

} 

Known-Length Field Section { 
Length (i), 
(Paisalea) (Msi (oe) cone 

} 


Known-Length Content { 
Content Length (i), 
Content (..), 


Known-Length Informational Response { 
Informational Response Control Data (..), 
Known-Length Field Section (..), 


Figure 1: Known-Length Message 


A known-length request consists of a framing indicator (Section 3.3), request control data 
(Section 3.4), a header section with a length prefix, binary content with a length prefix, a trailer 
section with a length prefix, and padding. 


A known-length response contains the same fields, with the exception that request control data is 
replaced by zero or more informational responses (Section 3.5.1) followed by response control 
data (Section 3.5). 


For a known-length encoding, the length prefix on field sections and content is a variable-length 
encoding of an integer. This integer is the number of bytes in the field section or content, not 
including the length field itself. 


Fields in the header and trailer sections consist of a length-prefixed name and length-prefixed 
value; see Section 3.6. 


The format allows for the message to be truncated before any of the length prefixes that precede 
the field sections or content; see Section 3.8. 
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The variable-length integer encoding means that there is a limit of 262-1 bytes for each field 
section and the message content. 


3.2. Indeterminate-Length Messages 


A request or response that is constructed without encoding a known length for each section uses 
the format shown in Figure 2: 


Indeterminate-Length Request { 
Framing Indicator (i) = 2, 
Request Control Data (..), 
Indeterminate-Length Field Section (..), 
Indeterminate-Length Content (..), 
Indeterminate-Length Field Section (..), 
Padding (..), 

} 


Indeterminate-Length Response { 
Framing Indicator (i) = 3, 
Indeterminate-Length Informational Response (..) 
Final Response Control Data (..), 
Indeterminate-Length Field Section (..), 
Indeterminate-Length Content (..), 
Indeterminate-Length Field Section (..), 
Padding (..), 

} 


Indeterminate-Length Content { 
Indeterminate-Length Content Chunk (..) ..., 
Content Terminator (i) = @, 


} 


Indeterminate-Length Content Chunk { 
Chunk Length (i) = 1.., 
Chunk (..), 


Indeterminate-Length Field Section { 
paxsala) (LSI (Coe) cong 
Content Terminator (i) = @, 


} 


Indeterminate-Length Informational Response { 
Informational Response Control Data (..), 
Indeterminate-Length Field Section (..), 


Figure 2: Indeterminate-Length Message 


An indeterminate-length request consists of a framing indicator (Section 3.3), request control 
data (Section 3.4), a header section that is terminated by a zero value, any number of non-zero- 
length chunks of binary content, a zero value, a trailer section that is terminated by a zero value, 
and padding. 
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An indeterminate-length response contains the same fields, with the exception that request 
control data is replaced by zero or more informational responses (Section 3.5.1) and response 
control data (Section 3.5). 


The indeterminate-length encoding only uses length prefixes for content blocks. Multiple length- 
prefixed portions of content can be included, each prefixed by a non-zero Chunk Length integer 
describing the number of bytes in the block. The Chunk Length is encoded as a variable-length 
integer. 


Each Field Line in an Indeterminate-Length Field Section starts with a Name Length field. An 
Indeterminate-Length Field Section ends with a Content Terminator field. The zero value of the 
Content Terminator distinguishes it from the Name Length field, which cannot contain a value of 
0. 


Indeterminate-length messages can be truncated in a way similar to that for known-length 
messages; see Section 3.8. 


Indeterminate-length messages use the same encoding for Field Line as known-length messages; 
see Section 3.6. 


3.3. Framing Indicator 


The start of each binary message is a framing indicator that is a single integer that describes the 
structure of the subsequent sections. The framing indicator can take just four values: 


e A value of 0 describes a request of known length. 

e A value of 1 describes a response of known length. 

e A value of 2 describes a request of indeterminate length. 

e A value of 3 describes a response of indeterminate length. 


Other values cause the message to be invalid; see Section 4. 


3.4. Request Control Data 


The control data for a request message contains the method and request target. That information 
is encoded as an ordered sequence of fields: Method, Scheme, Authority, Path. Each of these fields 
is prefixed with a length. 


The values of these fields follow the rules in HTTP/2 (Section 8.3.1 of [HTTP/2]) that apply to the 
":method", ":scheme", ":authority", and ":path" pseudo-header fields, respectively. However, 
where the ":authority" pseudo-header field might be omitted in HTTP/2, a zero-length value is 


encoded instead. 


The format of request control data is shown in Figure 3. 
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Request Control Data { 
Method Length (i), 


Method (..), 
Scheme Length (i), 
Scheme (..), 


Authority Length (i), 
Authority (..), 
Path Length (i), 
Path (..), 
} 


Figure 3: Format of Request Control Data 


3.5. Response Control Data 


The control data for a response message consists of the status code. The status code (Section 15 of 
[HTTP]) is encoded as a variable-length integer, not a length-prefixed decimal string. 


The format of final response control data is shown in Figure 4. 


Final Response Control Data { 
Status Code (i) = 200..599, 
} 


Figure 4: Format of Final Response Control Data 


3.5.1. Informational Status Codes 


Responses that include informational status codes (see Section 15.2 of [HTTP]) are encoded by 
repeating the response control data and associated header section until a final status code is 
encoded; that is, a Status Code field with a value from 200 to 599 (inclusive). The status code 
distinguishes between informational and final responses. 


The format of the informational response control data is shown in Figure 5. 


Informational Response Control Data { 
Status Code (i) = 100..199, 


Figure 5: Format of Informational Response Control Data 


A response message can include any number of informational responses that precede a final 
status code. These convey an informational status code and a header block. 


If the response control data includes an informational status code (that is, a value between 100 
and 199 inclusive), the control data is followed by a header section (encoded with known length 
or indeterminate length according to the framing indicator) and another block of control data. 
This pattern repeats until the control data contains a final status code (200 to 599 inclusive). 
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3.6. Header and Trailer Field Lines 


Header and trailer sections consist of zero or more field lines; see Section 5 of [HTTP]. The format 
of a field section depends on whether the message is of known length or indeterminate length. 


Each Field Line encoding includes a name and a value. Both the name and value are length- 
prefixed sequences of bytes. The Name field is a minimum of one byte. The format of a Field Line 
is shown in Figure 6. 


Field Line { 
Name Length (i) = 1.., 
Name (..), 
Value Length (i), 
Value (..), 

} 


Figure 6: Format of a Field Line 


For field names, byte values that are not permitted in an HTTP field name cause the message to 
be invalid; see Section 5.1 of [HTTP] for a definition of what is valid and Section 4 regarding the 
handling of invalid messages. A recipient MUST treat a message that contains field values that 
would cause an HTTP/2 message to be malformed according to Section 8.2.1 of [HTTP/2] as 
invalid; see Section 4. 


The same field name can be repeated over more than one field line; see Section 5.2 of [HTTP] for 
the semantics of repeated field names and rules for combining values. 


Messages are invalid (Section 4) if they contain fields named ":method", ":scheme", 
":authority", ":path", or '":status". Other pseudo-fields that are defined by protocol 
extensions MAY be included; pseudo-fields cannot be included in trailers (see Section 8.1 of 
[HTTP/2]). A Field Line containing pseudo-fields MUST precede other Field Line values. A message 
that contains a pseudo-field after any other field is invalid; see Section 4. 


Fields that relate to connections (Section 7.6.1 of [HTTP]) cannot be used to produce the effect on 
a connection in this context. These fields SHOULD be removed when constructing a binary 
message. However, they do not cause a message to be invalid (Section 4); permitting these fields 
allows a binary message to capture messages that are exchanged in a protocol context. 


Like HTTP/2 or HTTP/3, this format has an exception for the combination of multiple instances of 
the Cookie field. Instances of fields with the ASCII-encoded value of "cookie" are combined 
using a semicolon octet (0x3b) rather than a comma; see Section 8.2.3 of [HTTP/2]. 


3.7. Content 


The content of messages is a sequence of bytes of any length. Though a known-length message 
has a limit, this limit is large enough that it is unlikely to be a practical limitation. There is no 
limit to the size of content in an indeterminate-length message. 
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3.8. Padding and Truncation 


Messages can be padded with any number of zero-valued bytes. Non-zero padding bytes cause a 
message to be invalid (see Section 4). Unlike other parts of a message, a processor MAY decide not 
to validate the value of padding bytes. 


Truncation can be used to reduce the size of messages that have no data in trailing field sections 
or content. If the trailers of a message are empty, they MAY be omitted by the encoder in place of 
adding a length field equal to zero. An encoder MAY omit empty content in the same way if the 
trailers are also empty. A message that is truncated at any other point is invalid; see Section 4. 


Decoders MUST treat missing truncated fields as equivalent to having been sent with the length 
field set to zero. 


Padding is compatible with truncation of empty parts of the messages. Zero-valued bytes will be 
interpreted as a zero-length part, which is semantically equivalent to the part being absent. 


4. Invalid Messages 


This document describes a number of ways that a message can be invalid. Invalid messages 
MUST NOT be processed further except to log an error and produce an error response. 


The format is designed to allow incremental processing. Implementations need to be aware of 
the possibility that an error might be detected after performing incremental processing. 


5. Examples 
This section includes example requests and responses encoded in both known-length and 
indeterminate-length forms. 


5.1. Request Example 
The example HTTP/1.1 message in Figure 7 shows the content in the "message/http" format. 
Valid HTTP/1.1 messages require lines terminated with CRLF (the two bytes 0x0d and 0x0a). For 


simplicity and consistency, the content of these examples is limited to text, which also uses CRLF 
for line endings. 


GET /hello.txt HTTP/1.1 

User-Agent: curl/7.16.3 libcurl/7.16.3 OpenSSL/@.9.71 zlib/1.2.3 
Host: www.example.com 

Accept-Language: en, mi 


Figure 7: Sample HTTP Request 
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This can be expressed as a binary message (type "message/bhttp") using a known-length 
encoding as shown in hexadecimal in Figure 8. Figure 8 includes text alongside to show that most 
of the content is not modified. 


00034745 54056874 74707300 0a2f6865 ..GET.https../he 
6c6c6f2e 74787440 6c0a7573 65722d61 1lo.txt@l.user-a 
67656e74 34637572 6c2f372e 31362e33 gent4curl/7.16.3 
206c6962 6375726c 2f372e31 362e332@ libcurl/7.16.3 
4f70656e 53534c2f 302e392e 376c207a OpenSSL/@.9.71 z 
6c69622f 312e322e 3304686f 73740f77 lib/1.2.3.host.w 
77772e65 78616d78 6c652e63 6f6d@f61 ww.example.com.a 
63636578 742d6c61 6e677561 67650665 ccept-language.e 
6e2c206d 690000 Mie mis: 


Figure 8: Known-Length Binary Encoding of Request 


This example shows that the Host header field is not replicated in the ": authority" field, as is 
required for ensuring that the request is reproduced accurately; see Section 8.3.1 of [HTTP/2]. 


The same message can be truncated with no effect on interpretation. In this case, the last two 
bytes -- corresponding to content and a trailer section -- can each be removed without altering 
the semantics of the message. 


The same message, encoded using an indeterminate-length encoding, is shown in Figure 9. As the 
content of this message is empty, the difference in formats is negligible. 


02034745 54056874 74707300 0a2f6865 ..GET.https../he 
6c6c6f2e 7478740a 75736572 2d616765 llo.txt.user-age 
6743463 75726c2f 372e3136 2e33206c nt4curl/7.16.3 1 
69626375 726c2f37 2e31362e 33204f78 ibcurl/7.16.3 Op 
656e5353 4c2f302e 392e376c 207a6c69 enSSL/@.9.71 zli 
622f312e 322e3304 686f7374 O@f777777 + b/1.2.3.host.www 
2e657861 6d706c65 2e636f6d 0f616363 .example.com.acc 
6570742d 6c616e67 75616765 86656e2c ept-language.en, 
206d6900 00O0OOOOOO OO0O0OOOOO OOOOOOOO 6OCmi............. 


Figure 9: Indeterminate-Length Binary Encoding of Request 


This indeterminate-length encoding contains 10 bytes of padding. As two additional bytes can be 
truncated in the same way as the known-length example, anything up to 12 bytes can be 
removed from this message without affecting its meaning. 


5.2. Response Example 


Response messages can contain interim (1xx) status codes, as the message in Figure 10 shows. 
Figure 10 includes examples of informational status codes 102 and 103, as defined in [RFC2518] 
(now obsolete but defines status code 102) and [RFC8297], respectively. 
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HTTP/1.1 102 Processing 
Running: "sleep 15" 


HTTP/1.1 103 Early Hints 
Link: </style.css>; rel=preload; as=style 
Link: </script.js>; rel=preload; as=script 


AN eye hel 


Date: Mon, 


200 OK 


Server: Apache 
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT 
ETag: "34aa387-d-1568eb00" 
Accept-Ranges: bytes 


Content-Length: 51 


Vary: Accept-Encoding 
Content-Type: text/plain 


Binary HTTP Messages 


27 Jul 2009 12:28:53 GMT 


Hello World! My content includes a trailing CRLF. 


Figure 10: Sample HTTP Response 


August 2022 


As this is a longer example, only the indeterminate-length encoding is shown in Figure 11. Note 


here that the specific text used in the reason phrase is not retained by this encoding. 


03406607 
65702031 
2737479 
3d707265 
6c65046c 
2e6a733e 
643b2061 
64617465 
20323030 
4d540673 
0d6c6173 
65642c20 
31393a31 
67142233 
38656230 
6e676573 
6e742d6c 
7904163 
670c636f 
6578742 
20576172 
6e742069 
61696c69 


72756e6e 
35220040 
6c652e63 
6c6f6164 
696e6b24 
3b207265 
733d7363 
1d4d6f6e 
39203132 
65727665 
742d6d6f 
3232204a 
353a3536 
34616133 
30220d61 
05627974 
656e6774 
63657074 
6e74656e 
706c6169 
6c642120 
6e636c75 
6e672043 


696e670a 
67046c69 
73733e3b 
3b206173 
3217363 
6c3d7072 
72697074 
20203237 
3a32383a 
72064170 
64696669 
756c2032 
20474d54 
38372d64 
63636570 
65730e63 
68023531 
2d456e63 
742d7479 
6e003348 
4d792063 
64657320 
524c462e 


22736c65 
6e6b233c 
2072656c 
3d737479 
72697074 
656c6f61 
0040c804 
204a756c 
35332047 
61636865 
65641d57 
30303920 
04657461 
2d313536 
742d7261 
6f6e7465 
04766172 
6f64696e 
70650a74 
656c6c6f 
6f6e7465 
61207472 
odða000ð 


.@f . running. "sle 
ep 15".@g.link#< 
/style.css>; rel 
=preload; as=sty 
le.link$</script 
.js>; rel=preloa 
d; as=script.@.. 
date.Mon, 27 Jul 
2009 12:28:53 G 
MT.server.Apache 
. last-modified.W 
ed, 22 Jul 2009 

19:15:56 GMT.eta 
g."34aa387-d-156 
8eb00" .accept-ra 
nges.bytes.conte 
nt-length.51.var 
y .Accept-Encodin 
g.content-type.t 
ext/plain.3Hello 
World! My conte 
nt includes a tr 
alang ERIE ee. 


Figure 11: Binary Response, including Informational Responses 
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A response that uses the chunked encoding (see Section 7.1 of [HTTP/1.1]) as shown in Figure 12 
can be encoded using indeterminate-length encoding, which minimizes buffering needed to 
translate into the binary format. However, chunk boundaries do not need to be retained, and any 
chunk extensions cannot be conveyed using the binary format; see Section 6. 


HTTP/1.1 200 OK 
Transfer-Encoding: chunked 


A 
This 
6 
conte 
13 ;chunk-extension=foo 
nt contains CRLF. 


(2] 
Trailer: text 


Figure 12: Chunked Encoding Example 


Figure 13 shows this message using the known-length encoding. Note that the Transfer-Encoding 
header field is removed. 


0140c8090 1d546869 7320636f 6e74656e .@...This conten 
7420636f 6e746169 6e732043 524c462e t contains CRLF. 
Ədðaðdð7 74726169 6c657204 74657874 ....trailer.text 


Figure 13: Known-Length Encoding of Response 


6. Notable Differences with HTTP Protocol Messages 


This format is designed to carry HTTP semantics just like HTTP/1.1 [HTTP/1.1], HTTP/2 [HTTP/2], 
or HTTP/3 [HTTP/3]. However, there are some notable differences between this format and the 
format used in an interactive protocol version. 


In particular, as a standalone representation, this format lacks the following features of the 
formats used in those protocols: 


e chunk extensions (Section 7.1.1 of [HTTP/1.1]) and transfer encoding (Section 6.1 of [HTTP/ 
1,1) 


e generic framing and extensibility capabilities 

e field blocks other than a single header and trailer field block 
e carrying reason phrases in responses (Section 4 of [HTTP/1.1]) 
e header compression [HPACK] [QPACK] 
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e response framing that depends on the corresponding request (such as HEAD) or the value of 
the status code (such as 204 or 304); these responses use the same framing as all other 
messages 


Some of these features are also absent in HTTP/2 and HTTP/3. 


Unlike HTTP/2 and HTTP/3, this format uses a fixed format for control data rather than using 
pseudo-fields. 


Note that while some messages -- CONNECT or upgrade requests in particular -- can be 
represented using this format, doing so serves no purpose, as these requests are used to affect 
protocol behavior, which this format cannot do without additional mechanisms. 


7. "message/bhttp" Media Type 

The "message/bhttp" media type can be used to enclose a single HTTP request or response 
message, provided that it obeys the MIME restrictions for all "message" types regarding line 
length and encodings. 

Type name: message 

Subtype name: bhttp 

Required parameters: N/A 

Optional parameters: N/A 

Encoding considerations: Only "8bit" or "binary" is permitted. 

Security considerations: See Section 8. 

Interoperability considerations: N/A 

Published specification: RFC 9292 


Applications that use this media type: Applications seeking to convey HTTP semantics that are 
independent of a specific protocol. 


Fragment identifier considerations: N/A 


Additional information: Deprecated alias names for this type: N/A 
Magic number(s): N/A 
File extension(s): N/A 
Macintosh file type code(s): N/A 
Person & email address to contact for further information: See the Authors’ Addresses section. 


Intended usage: COMMON 


Restrictions on usage: N/A 


Thomson & Wood Standards Track Page 14 


RFC 9292 Binary HTTP Messages August 2022 


Author: See the Authors' Addresses section. 


Change controller: IESG 


8. Security Considerations 


Many of the considerations that apply to HTTP message handling apply to this format; see 
Section 17 of [HTTP] and Section 11 of [HTTP/1.1] for common issues in handling HTTP messages. 


Strict parsing of the format with no tolerance for errors can help avoid a number of attacks. 
However, implementations still need to be aware of the possibility of resource exhaustion 
attacks that might arise from receiving large messages, particularly those with large numbers of 
fields. 


Implementations need to ensure that they aren't subject to resource exhaustion attacks from 
maliciously crafted messages. Overall, the format is designed to allow for minimal state when 
processing messages. However, producing a combined field value (Section 5.2 of [HTTP]) for 
fields might require the commitment of resources. In particular, combining might be necessary 
for the Cookie field when translating this format for use in other contexts, such as use in an API 
or translation to HTTP/1.1 [HTTP/1.1], where the recipient of the field might not expect multiple 
values. 


9. IANA Considerations 


IANA has added the media type "message/bhttp" to the "Media Types" registry at <https:// 
www.iana.org/assignments/media-types>. See Section 7 for registration information. 
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